bump go-subjectid to v0.2.0 and adopt its value-form subjects#17
Merged
Conversation
go-subjectid v0.2.0 is a breaking release: Parse now returns Subject
Identifiers in their value form (subjectid.IssSubID) rather than the
pointer form (*subjectid.IssSubID), and value receivers now satisfy the
SubjectIdentifier interface. The previous pin was a v0.0.0 pseudo-version
whose Parse still handed back pointers, which is the behavior the SET
type and its tests were written against.
Adapting the dependent code is mechanical but spreads across the parse
boundary. Every test that type-asserts a parsed top-level or per-event
sub_id — in conformance_test.go, interop_test.go, parse_test.go, and
subject_test.go — moves from .(*subjectid.IssSubID) with a pointer
dereference to .(subjectid.IssSubID) with a direct value comparison,
matching what Parse now returns. The SET.Subject field doc, the
SubjectAs godoc, and the ExampleSET_IssSub doc previously explained the
value/pointer split by saying "Parse yields the pointer form because
go-subjectid's registry constructors return pointers"; that rationale is
now false, so they instead state that Parse yields the value form and
that the pointer form arises only from a hand-built SET.
This does not simplify SubjectAs or IssSub. v0.2.0 removes the
asymmetry those accessors were first written to bridge, but a consumer
can still assign a *subjectid.IssSubID to the Subject interface field, so
the reflection-based pointer-peel path and its TestSubjectAsPointerForm /
typed-nil coverage stay. encode_test.go keeps its &subjectid.IssSubID{}
literal for the same reason: it now doubles as proof that a pointer-form
subject still encodes correctly.
The change is observable to consumers — code that asserted a parsed
subject as *subjectid.IssSubID must now assert the value form — so it is
a breaking change. Pre-1.0 SemVer signals that with a minor bump; the
CHANGELOG records it under a dated [0.2.0] entry marked Breaking, and
notes that consumers already reading the subject through SubjectAs or
IssSub need no changes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Upgrades
github.com/hstern/go-subjectidfrom the priorv0.0.0pseudo-version to v0.2.0 and adapts go-secevent to it.Why
go-subjectid v0.2.0 is a breaking release:
subjectid.Parsenow returns Subject Identifiers in their value form (subjectid.IssSubID) rather than the pointer form (*subjectid.IssSubID), and value receivers now satisfy thesubjectid.SubjectIdentifierinterface. The old pin'sParsestill returned pointers — the shape theSETtype and its tests were written against.Changes
go-subjectid→v0.2.0.conformance_test.go,interop_test.go×2,parse_test.go,subject_test.go) — parsedsub_idtype asserts move from.(*subjectid.IssSubID)+ pointer deref to.(subjectid.IssSubID)+ direct value comparison, matching whatParsenow returns.secevent.goSET.Subject,subject.goSubjectAs+ an inline comment,example_test.goExampleSET_IssSub) — the now-false "Parse yields the pointer form because go-subjectid's constructors return pointers" rationale is rewritten to state Parse yields the value form, with the pointer form arising only from a hand-builtSET.[0.2.0]entry, marked Breaking:, plus updated link references.Deliberately unchanged
SubjectAs/IssSubreflection-based pointer-peel path,TestSubjectAsPointerForm, and the typed-nil subtest — a consumer can still assign a*subjectid.IssSubIDto theSubjectinterface field, so the pointer-handling path stays valid.encode_test.go's&subjectid.IssSubID{}literal — now doubles as proof that a pointer-form subject still encodes correctly.Consumer impact (breaking)
Code that asserted a parsed subject as
*subjectid.IssSubIDmust now assert the value form. Consumers already reading the subject throughSubjectAs[T]orSET.IssSubneed no changes — those accessors return the value form either way. Pre-1.0 SemVer signals the break with the minor bump tov0.2.0.Verification
Local CI mirror all green:
gofmt -l,go vet ./...,go mod tidy -diff,go test -race -shuffle=on ./..., andgolangci-lint v2.12.2 run ./...(0 issues). Pre-PRcc-skills-golangdocumentation + testing skills run; code review clean.🤖 Generated with Claude Code